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(57) ABSTRACT 

A telecommunications switch management system which 
contains a system manager building block in communication 
with a remote computer. The system manager building block 
is also in communication with a system management inter- 
face building block, which contains a command interpreter 
building block and a system command interface building 
block. The command interpreter building block is in com- 
munication with the system manager building block and the 
system command interface building block. The system com- 
mand interface building block contains at least one client 
building block. The client building blocks located in the 
system command interface building block are each in com- 
munication with a corresponding server building block, each 
of which in turn is in communication with the telecommu- 
nications switching system. The system manager building 
block provides communication between the remote com- 
puter and the system management interface building block. 
The system management interface building block provides 
communication between the system manager building block 
and the one or more servers which are in communication 
with the telecommunications switching system. 
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TELECOMMUNICATIONS SWITCH 
MANAGEMENT SYSTEM 

TECHNICAL FIELD OF THE INVENTION 

The present invention relates in general to the field of 
telecommunications switching systems. More particularly, 
the present invention is related to a Telecommunications 
Switch Management System for use with telecommunica- 
tions switching systems. 

BACKGROUND OF THE INVENTION 

Conventional telecommunications switching systems 
employ centralized switching facilities which result in unde- 
sirable lengthy switching paths. Therefore, it is desirable to 
implement distributed telecommunications switching sys- 
tems which do not require centralized switching facilities. 
However, elaborate management systems normally are 
required in order to provide users and operators with the 
ability to control, configure and monitor the various 
switches and other components which make up a typical 
distributed telecommunications switching system For 
example, an operator or user must be able to control, 
configure and monitor a distributed switching system's 
individual application cards, as well as the communication 
busses which interconnect those application cards 

Conventional distributed telecommunications switching 
systems use dedicated Operational Support Systems 
("OSSs") and relatively complex and cryptic command - 
driven user interface systems in order to provide users with 
the ability to control, configure and monitor distributed 
switching systems. These dedicated OSSs are cumbersome 
to develop, maintain, upgrade and expand upon. 
Additionally, the command-driven user interfaces are rela- 
tively cryptic, cumbersome, non-intuitive and difficult for 
users to learn and use. 

The dedicated OSSs which provide management and 
support functions for telecommunications switching systems 
are relatively inflexible and difficult to develop, maintain, 
upgrade and expand because they normally use dedicated 
architectures, rather than more desirable and flexible open 
architectures Additionally, the architectures for these dedi- 
cated OSSs normally are unsuitable for interfacing with 
standardized communications links such as intranets or the 
internet. Therefore, a need has arisen for a telecommunica- 
tions switch management and support system which will 
provide increased flexibility, upgradability, expandability, 
and ease of development and maintenance. 

SUMMARY OF THE INVENTION 

In accordance with the present invention, a telecommu- 
nications switch management system is provided which 
substantially eliminates or reduces the disadvantages and 
problems associated with prior management systems for 
distributed telecommunications switching systems 

The telecommunications switch management system of 
the present invention is flexible and relatively easy to 
develop, maintain, upgrade and expand. Additionally, the 
telecommunications switch management system can inter- 
face with standardized communications links such as the 
Internet. The telecommunications switch management sys- 
tem of the present invention enables one or more users to 
remotely access the telecommunications switching system 
for any desired purpose, such as to monitor, control or 
reconfigure the telecommunications switching system. 

The telecommunications switch management system of 
the present invention contains a system manager building 
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block in communication with a remote computer. The sys- 
tem manager building block is also in communication with 
a system management interface building block, which con- 
tains a command interpreter building block and a system 

5 command interface building block. The command inter- 
preter building block is in communication with the system 
manager building block and the system command interface 
building block. The system command interface building 
block contains at least one client building block. The client 

1Q building blocks located in the system command interface 
building block are each in communication with a corre- 
sponding server building block, each of which in turn is in 
communication with the telecommunications switching sys- 
tem. The system manager building block provides commu- 
nication between the remote computer and the system man- 

15 agement interface building block. The system management 
interface building block provides communication between 
the system manager building block and the one or more 
servers which are in communication with the telecommuni- 
cations switching system. 

20 In another aspect of the invention, the client building 
blocks and server building blocks can include a system 
security manager client building block in communication 
with a system security manager server building block for 
providing the telecommunications switching system with 

25 various security functions. In still another aspect of the 
invention, the client building blocks and server building 
blocks can include a bearer manager client building block in 
communication with a bearer manager server building block 
for providing users with the ability to perform various 

30 management and monitoring functions on the telecommu- 
nications switching system. In yet another aspect of the 
invention, the client building blocks and server building 
blocks can include a fault manager client building block in 
communication with a fault manager server building block 

35 for providing users with the ability to review various types 
of faults which have occurred in the telecommunications 
switching system. In another aspect of the invention, the 
client building blocks and server building blocks can include 
a test manager client building block in communication with 

40 a test manager server building block for providing users with 
the ability to perform various tests on the telecommunica- 
tions switching system. In still another aspect of the 
invention, the client building blocks and server building 
blocks can include a performance manager client building 

45 block in communication with a performance manager server 
building block for providing users with the ability to review 
the performance of the telecommunications switching sys- 
tem. In yet another aspect of the invention, the client 
building blocks and server building blocks can include a 

50 configuration management client building block in commu- 
nication with a configuration management server building 
block for providing users with the ability to configure the 
various attributes of the telecommunications switching sys- 
tem. 

55 In another aspect of the invention, the remote computer 
communicates with the system manager building block 
using the Internet inter-ORB (Object Request Broker) pro- 
tocol ("HOP*') or the Hypertext Transport Protocol 
("HTTP"). In still another aspect of the invention, the 

60 various building blocks of the telecommunications switch 
management system can communicate with one another by 
sending and receiving messages In yet another aspect of the 
invention, the various building blocks of the telecommuni- 
cations switch management system can be designed using 

65 the well-known Common Object Request Broker Architec- 
ture ("CORBA"), and can communicate with one another 
using the CORBA communications protocol. 
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A technical advantage of the telecommunications switch present invention. The distributed Telecommunications 
management system of the present invention is its ability to Switching System 230 includes a Service Unit Subsystem 
provide multiple users remote access to telecommunications 232 which provides control and management on an 
switching systems, for all of the same purposes as would be advanced intelligent network ("AIN") service platform 
available using a dedicated'terminal located proximate to the 5 "sing information network architecture ("INA") software 
telecommunications switching system. Another technical *«ign principles. Distributed Telecommunications Switch- 
advantage of the telecommunications switch management «ig System 230 also includes a plurahty of Delivery Unit 
system of the present invention is its design flexibility and Subsystems 234 that provide the message transport mecha- 
the relative ease with which it can be developed, maintained, J" 0 . 6 " «? "Ration under the control and I direction of 
upgraded and expanded. Still another technical advantage of 10 Service Unit Subsystem 232. Service Unit Subsystem 232 
the telecommunications switch management system of the and " n " S " bs ^ Ie .^ M4 ~ mmU " lC f WUh 006 
present invention is its ability to interface with standardized another th ™"8 n a ^ °P» C 23« <*jl ^formation is 
communications links such as the Internet, and to use tansported between the mulUple Delivery Unit Subsystems 
standardized CORBA architectures and communications 234, and between each Delivery Unit Subsystem 234 and 

, , is Service Uml Subsystem 232 on Fiber Optic Ring 236, 

preferably in asynchronous transfer mode ("ATM") cell 

BRIEF DESCRIPTION OF THE DRAWINGS formal 

For a more complete understanding of the present inven- The Service Unit Subsystem 232 provides the control and 

lion and the advantages thereof, reference is now made to management functions for the distributed Telecommunica- 

the following description taken in conjunction with the 20 »>° ns Switchin g s y*° m 23 ». ^ » »P»™)«d **** «» 

accompanying drawings in which like references indicate !™ s P° r ! *«bamsm tunrtion of Delivery Unit Subsystems 

like features and wherein: ?34. This separation ot functionality between the Service 

T-i/-x * • i_- i_ t i li i j * c iL i i Unit Subsystem 232 and the Delivery Unit Subsystems 234 

FIG. lis a .high-level block diagram of the telecommu- al]ows each sub tem l0 evolve aod be upgraded 

nications switch management system of the present inven- ^ mdependently> in 0 ' rder t0 support new Kr/kM ** new 

10n technologies for enhancements to either subsystem. The 

FIG. 2 is an exemplary process flow diagram for the Servicc Unil Subsystem 232 can be constructed to support 

operation of the GUI Launcher of the present invention. multiple types of Delivery Unit Subsystems 234 which can 

FIGS, 3A-B are exemplary process flow diagrams for the provide multiple services including broadband, video, con- 
operation of the Full Group Privileges Access Mechanism of 3fl ventional telephone, and personal communications services 
the present invention. to consumers on the public telephony network Service Unit 

FIG. 4 is an exemplary first display in the series of Subsystem 232 and Delivery Unit Subsystems 234 of the 

displays provided by the Graphical Shelf Navigator of the distributed Telecommunications Switching System 230 may 

present invention, either be grouped within a single geographic area or may be 

FIG. 5 is an exemplary next display in the series of 35 geographically disbursed in several remote areas while 

displays provided by the Graphical Shelf Navigator of the maintaining the same distributed nature of the switching 

present invention. function to be performed 

FIG. 6 is an exemplary next and final display in the series The centralized control and management provided by 

of displays provided by the Graphical Shelf Navigator of the Service Unit Subsystem 232 allows a user to be connected 

present invention. 40 to different Delivery Unit Subsystems 234 while main tain - 

FIG. 7 is an exemplary process flow diagram for the a common directory number Delivery Unit Subsystem 

operation of the Graphical Shelf Navigator of the present 234 Provides the switching fabric : for distributed Telecom- 

invention murucations Switching System 230. Delivery Unit Sub- 

™~ 0 . 1 j • 1 c *t_ 11 j c systems 234 may be dedicated to a specific type of service 

FIG. 8 is an exemplary display of the pull-down menus of J J , . u . . . Jr 

lL . ,. , OL ,/ XT . , c lL 45 or may accommodate multiple services. 

the Graphical Shelf Navigator of the present invention. ^ ' , _ . „ . 

A . . . ... c . „ , The Fiber Optic Ring 236 allows the communication of 

FIG. 9 is another exemplary display of the pull-down c ^ ^ ^ (includi vid dat 

menus of the Graphical Shelf Navigator of the present image and vQice) and operatio ^ a ^ mimstra t ion , mainte- 

mvention nance and provisioning ("OAM&P"). Fiber Optic Ring 236 

FIG. 10 is an exemplary process flow diagram for the 5Q provides quality information transmission and dual physical 
operation of the pull-down menus of the Graphical Shelf path ^^mission capability between the Service Unit Sub- 
Navigator of the present invention syslem 232 and Delivery Unit Subsystems 234. Information 

FIG. 11 is an exemplary Login Screen provided by the m ay be transmitted between subsystems along one portion 

GUI Launcher of the present invention. 0 f the Fiber Optic Ring 236, leaving the other portions of the 

FIG. 12 is an exemplary top-level display screen provided 55 Fiber Optic Ring 236 available for simultaneous transmis- 

by the GUI Launcher of the present invention sions between other subsystems within the distributed Tele- 

FIG, 13 is an exemplary next-level display screen pro- communication Switching System 230. Additionally, dis- 

vided by the GUI Launcher of the present invention. tributed Telecommunications Switching System 230 can 

FIG. 14 is a high-level block diagram of a distributed dynamically allocate and reallocate bandwidths for Fiber 

telecommunications switching system which utilizes the 60 Optic Ring 236 transmission in order to accommodate 

telecommunications switch management system of the P eriocls of increased information demand, 

present invention. Other features of distributed Telecommunications Switch- 
ing System 230 include, but are not limited to, industry - 

DETAILED DESCRIPTION OF THE standard operating systems, object-oriented development 

INVENTION 65 methodology, C++ implementation language, location- 

F1G. 14 depicts a block diagram of a distributed Tele- transparent interfaces using CORBA (Common Object 

communications Switching System 230 which utilizes the Request Broker Architecture), a name-based messaging 
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system, a well-defined OAM &P architecture, management 
interfaces, and encapsulation and intelligence. These and 
other features of distributed Telecommunications Switching 
System 230 are further described in U.S. Pat. No. 5,495,484, 
which is hereby incorporated by reference. CORBA is fully 5 
described in "The Common Object Request Broker: Archi- 
tecture and Specification," which is published by the Object 
Management Group and X Open, and which is hereby 
incorporated by reference. 

The present invention provides a Telecommunications 10 
Switch Management System for operation with distributed 
Telecommunications Switching System 230. FIG. 1 depicts 
a high-level block diagram of the Telecommunications 
Switch Management System of the present invention, 
including the various software building blocks which com- 15 
prise the Telecommunications Switch Management System 
of the present invention. A building block is defined to be 
one or more software objects and routines which can be 
deployed, upgraded and maintained in a software repository, 
and which also can be used by applications, either alone or 2 o 
in combination, in order to perform specific functions or 
operations. Additionally, building blocks normally have 
message interfaces. FIG. 1 depicts the following building 
blocks of the Telecommunications Switch Management Sys- 
tem of the present inventions each of which will be dis- 2 s 
cussed below in additional detail System Manager 18, 
System Security Manager Client 54, System Management 
Interface 56, System Security Manager Server 58, Com- 
mand Interpreter 62, System Command Interface 64, Bearer 
Manager Client 66, Fault Manager Client 68, Test Manager 30 
Client 70, Performance Manager Client 72, Configuration 
Management Client 74, Bearer Manager Server 76, Fault 
Manager Server 78, Test Manager Server 80, Performance 
Manager Server 82, and Configuration Management Server 

84 35 

The Telecommunications Switch Management System of 
the present invention preferably includes a Graphic User 
Interface (GUI) Launcher 8 for the Telecommunications 
Switch Management System. GUI Launcher 8 includes 
Remote Computer 10, communications link 12, Remote 40 
Server 14, communications link 16, and System Manager 
18. Remote Computer 10 in turn contains Browser software 
11. System Manager 18 in turn contains Runtime Library 
software 19. Remote Computer 10 serves as a GUI Browser 
and communicates via communications link 12 with Remote 45 
Server 14, and also via communications link 16 with System 
Manager 18, as will be further described. 

Browser 11 can be any type of system capable of access- 
ing telecommunications link 12 Server Page 20 resides on 
Remote Server 14 and contains the application program 50 
necessary to enable Remote Computer 10 to communicate 
with the Telecommunications Switching System 230. A user 
at Remote Computer 10 initiates a system access session by 
establishing communication over link 12 with Remote 
Server 14. In response, Remote Server 14 downloads the 55 
application program to Remote Computer 10, which enables 
Remote Computer 10 to communicate with Telecommuni- 
cations Switching System 230. Although this application 
program generally may be of any type, it typically is in the 
form of a Java Applet 22. Once Java Applet 22 has been 60 
loaded into Remote Computer 10, Remote Computer 10 can 
communicate in a stand-alone capacity with the Telecom- 
munications Switching System 230 through communica- 
tions link 16 and System Manager 18. Thus, once Java 
Applet 22 has been loaded into Manufacture and Sale of 65 
Tubes for Pneumatic Tires for Vehicle WheelsRemote Com- 
puter 10, Remote Computer 10 can communicate with the 
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Telecommunications Switching System 230 without the 
need for any further communication with Remote Server 14. 

The arrangement of GUI Launcher 8 enables one or more 
authorized users to access the Telecommunications Switch- 
ing System 230 from any location having a remote computer 
system. Thus, authorized users located anywhere can access 
the Telecommunications Switching System 230 for all of the 
same purposes as could a user of a dedicated terminal 
located proximate to the Telecommunications Switching 
System 230. These purposes include, for example, the test 
and reconfiguration of the Telecommunications Switching 
System 230, as well as the monitoring of the Telecommu- 
nications Switching System's performance, faults and secu- 
rity system. 

Although Remote Server 14 generally can be located 
anywhere, as depicted in FIG. 1, Remote Server 14 may for 
example be configured to be included within System Man- 
ager 18. In such a case where Remote Server 14 is included 
within System Manager 18, Remote Computer 10 would 
communicate with System Manager 18, and also with 
Remote Server 14 contained therein, via communications 
link 16. Communications link 12 therefore would not be 
required if Remote Server 14 were included within System 
Manager 18. 

Although Remote Computer 10 can be any type of 
computer system, it may comprise for example an ftSparc 
(fault-tolerant Sparc) workstation, which comprises a Sun 
Workstation and UNIX Solaris Operating System, or a 
personal computer (PC), including a portable PC such as a 
laptop computer. Similarly, although Remote Server 14 may 
be any type of servers it may comprise an HTML (Hypertext 
Markup Language) Server, for example. Additionally, 
Server Page 20 may for example comprise an HTML Page. 
Communication links 12 and 16 may be of any type, but may 
comprise for example an Incranet communications link or a 
telephone modem in combination with a standard Internet 
telephone line communications link. In the event that tele- 
communications link 12 is a standard Internet telephone 
line, Browser 11 may be any Web Browser, such as 
NETSCAPE or MICROSOFT'S INTERNET EXPLORER, 
for example. The communications protocol used by com- 
munications links 12 and 16 may comprise the HOP 
(Internet Inter-ORB (Object Request Broker) Protocol)) or 
HTTP (Hypertext Transport Protocol) protocols, for 
example. Although System Manager 18 can be any type of 
message passing and handling system, it may for example 
comprise a Message Object Stream System (MOSS) 

FIG. 2 depicts an exemplary process flow for the opera- 
tion of GUI Launcher 8 beginning with Block 24. In order 
to use GUI Launcher 8 to access the Telecommunications 
Switching System 230, a user at Remote Computer 10 
initializes Browser 11 to access telecommunications link 12, 
as shown in Block 24. As shown in Block 26, Browser 11 
then accesses Remote Server 14 via communications link 
12. In Block 28, Remote Computer 10 in combination with 
Browser 11 access the address of Server Page 20 which is 
located on Remote Server 14. Remote Server 14 then 
provides the address of Server Page 20 to Browser 11 
running on Remote Computer 10 As shown in Block 30, 
Remote Server 14 then provides Remote Computer 10 with 
the application program necessary to enable Remote Com- 
puter 10 to communicate with the Telecommunications 
Switching System 230. Typically, this application program 
is provided to Remote Computer 10 in the form of Java 
Applet 22. 

In Block 32, Remote Computer 10 in conjunction with 
Java Applet 22 provide the Remote Computer user's User 
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Identification (ID) and password to System Manager 18 via 
communications link 16. System Manager 18 contains Runt- 
ime Library 19, in which is maintained a database of 
authorized User IDs and passwords. Using its Runtime 
Library 19, System Manager 18 verifies the Remote Com- 5 
puter user's User ID and password, as shown in Block 34. 
As shown in Block 36, assuming the User ID and password 
are both valid, System Manager 18 establishes a socket 
connection between Remote Computer 10 and System Secu- 
rity Manager Client 54 within System Management Inter- 1Q 
face 56, depicted in FIG. 1. Although System Manager 18 
and System Management Interface 56 may be designed 
using any suitable software architecture, they may for 
example be designed using the well known CORBA archi- 
tecture 15 

System Security Manager Client 54, in conjunction with 
System Security Manager Server 58 which is part of Servers 
60, verifies the Remote Computer user's ID and Password 
against a database of User IDs and Passwords, as shown in 
Block 38. As shown in Blocks 40 and 42, if the user's User 20 
ID and Password are valid, System Security Manager Client 
54 sends a message to Remote Computer 10 indicating a 
successful logon. If on the other hand, either the user's User 
ID or Password is invalid, System Security Manager Client 
54 sends a message to Remote Computer 10 indicating that 25 
the logon attempt has failed, as shown in Blocks 40 and 44. 
System Management Interface 56, System Security Manager 
Client 54 and System Security Manager Server 58 will each 
be described in further detail below. 

In Block 46, once a successful logon has been established, 30 
Java Applet 22 in Remote Computer 10 launches and runs 
the GUI Launcher so that the Remote Computer user can 
access and control the Telecommunications Switching Sys- 
tem 230 from Remote Computer 10. As described 
previously, Remote Computer 10 in conjunction with Java 35 
Applet 22 operate in a stand-alone capacity without the need 
for additional communication between Remote Computer 
10 and Remote Server 14. While the GUI Launcher is 
running, Remote Computer 10 in conjunction with Java 
Applet 22 send messages representative of the Remote 40 
Computer user's input to System Manager 18, and also 
receive from System Manager 18 messages relating to the 
Telecommunications Switching System 230, as shown in 
Block 48. Additionally, in Block 50, System Security Man- 
ager Client 54 in conjunction with System Security Manager 45 
Server 58 maintain records regarding which Users have 
logged on, as well as when and for how long they each have 
logged on. 

When the user of Remote Computer 10 wishes to termi- 
nate the logon session, the user enters the appropriate 50 
command at Remote Computer 10, and the GUI Launcher 
sends a message instructing System Manager 18 to terminate 
the session, as shown in Block 52. When the logon session 
has been terminated, Remote Computer 10 does not retain 
Java Applet 22. Rather, for the next logon session from 55 
Remote Computer 10, Remote Server 14 again provides to 
Remote Computer 10, typically in the form of a Java Applet 
22, the application program which enables Remote Com- 
puter 10 to communicate with the Telecommunications 
Switching System 230. This eliminates the need to install eo 
and maintain multiple copies of the necessary application 
program on one or more Remote Computers 10. Instead, the 
necessary application program need only be installed, main- 
tained and updated on Remote Server 14. 

FIGS. 11-13 depict exemplary displays provided by GUI 65 
Launcher 8 for enabling a user to access the Telecommuni- 
cations Switch Management System of the present inven- 



tion. FIG. 11 depicts an exemplary Login Screen which 
prompts the user to enter a User ID and password The GUI 
Launcher 8 will not permit the user to continue to the next 
GUI Launcher display unless the user enters a valid User ID 
and password 

FIG. 12 depicts an exemplary top-level display provided 
by GUI Launcher 8p which would be generated if the user 
enters a valid User ID and password in the Login Screen 
depicted in FIG. 11 This top-level display provides the user 
with the first layer of selections regarding the type of access 
the user is seeking into the Telecommunications Switch 
Management System and the accompanying Telecommuni- 
cations Switching System 230. In the example depicted in 
FIG. 12! the user can select from the GUI Launcher 8 
options designated as "Monitor", "Configuration", 
"Applications", "Performance", and "Security*'. Other 
selections may also be provided instead of, or in addition to, 
the exemplary selections depicted in FIG. 12. 

FIG. 13. depicts an exemplary next-level display provided 
by GUI Launcher 8 The GUI Launcher 8 would generate the 
exemplary display depicted in FIG. 13 if the user selects the 
option designated as "Configuration" in the display depicted 
in FIG. 12. In the example depicted in FIG. 13, the user can 
select from options designated as "OC3 Configuration" and 
"OC3 Maintenance". These exemplary selections could for 
example provide the user access to the Graphical Shelf 
Navigator, which is discussed in additional detail below. 
Other selections may also be provided in addition to or 
instead of the exemplary selections depicted in FIG. 13. 

In addition to GUI Launcher 8, the system of FIG. 1 
provides additional unique elements of the Telecommuni- 
cations Switch Management System configured in a unique 
architecture so as to provide capabilities and flexibility not 
available in systems of the prior art. FIG. 1 depicts these 
additional elements and the architecture of the Telecommu- 
nications Switch Management System for operation with the 
Telecommunications Switching System 230. In particulars 
FIG. 1 depicts System Management Interface 56 which 
comprises Command Interpreter 62 and System Command. 
Interface 64. System Management Interface 56 communi- 
cates with Servers 60 in order to provide communication 
with the Telecommunications Switching System 230. Sys- 
tem Command Interface 64 comprises multiple Clients, 
namely System Security Manager Client 54, Bearer Man- 
ager Client 66, Fault Manager Client 68, Test Manager 
Client 70, Performance Manager Client 72 and Configura- 
tion Management Client 74. Servers 60 comprise multiple 
Servers, namely System Security Manager Server 58, Bearer 
Manager Server 76, Fault Manager Server 78, Test Manager 
Server 80, Performance Manager Server 82 and Configura- 
tion Management Server 84. Each Server communicates 
with a corresponding Client, as depicted in FIG. 1. 

System Management Interface 56 and Servers 60, in 
conjunction with GUI Launcher 8, permit users to access 
and communicate with the Telecommunications Switching 
System 230 for purposes such as the test and reconfiguration 
of the Telecommunications Switching System 230, as well 
as the monitoring of Telecommunications Switching System 
230's performance, faults and security system. Users may 
use Remote Computer 10 to send commands and messages 
to the Telecommunications Switching System 230, as well 
as to receive commands and messages therefrom. 

Commands and Messages can be sent and received 
between Remote Computer 10 and System Manager 18 via 
communications link 16. Additionally, System Manager 18 
can communicate with Command Interpreter 62 within 
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System Management Interface 56. System Manager 18 
processes commands and messages being sent by Remote 
Computer 10 to be compatible with, and suitable for receipt 
by, Command Interpreter 62, and also processes commands 
and messages being sent by Command Interpreter 62 to be 
compatible with, and suitable for receipt by, Remote Com- 
puter 10. Although communications link 16 may use any 
appropriate communications protocol, the protocol may 
comprise the HOP or HTTP protocols, for example. 
Additionally, although System Manager 18 and Command 
Interpreter 62 may be designed using any suitable software 
architecture, they may for example be designed using the 
well known CORBA architecture. In such a case where 
System Manager 18 and Command Interpreter 62 are 
designed using the CORBA architecture, System Manager 
18 and Command Interpreter 62 would communicate with 
one another using CORBA communications protocol. 

System Management Interface 56 serves to determine, for 
each message and command sent by Remote Computer 10 
via System Manager 18, which client located in System 
Command Interface 64 and which corresponding Server 60 
must be requested in order to implement that message or 
command. Command Interpreter 62, located within System 
Management Interface 56, interprets all messages and com- 
mands received from Remote Computer 10 via System 
Manager 18, before forwarding the message or command on 
to System Command Interface 64. System Command Inter- 
face 64, in conjunction with System Security Manager 
Client 54 and System Security Manager Server 58, then 
determines whether the user of Remote Computer 10 is 
authorized to implement the function or command received 
from Remote Computer 10 via System Manager 18. The 
security-related functions of System Security Manager Cli- 
ent 54 and System Security Manager Server 58 will be 
discussed below in additional detail 

Command Interpreter 62 can communicate with System 
Command Interface 64, and with Clients 54, 66, 68, 70, 72 
and 74 therein. Command Interpreter 62 processes com- 
mands and messages being sent by System Manager 18 of 
GUI Launcher 8 to be compatible with, and suitable for 
receipt by, System Command Interface 64, and also pro- 
cesses commands and messages being sent by System 
Command Interface 64 to be compatible with, and suitable 
for receipt by, System Manager 18 Although any appropriate 
communications protocol may be used for communication 
between Command Interpreter 62 and System Command 
Interface 64, the protocol may comprise the Library Appli- 
cation Programming Interface (API) protocol, for example. 

System Command Interface 64, and Clients 54, 66, 68, 70, 
72 and 74 therein, can communicate with Servers 60. Each 
Client in System Command Interface 64 communicates with 
a corresponding Server in Servers 60. More specifically, 
System Security Manager Client 54, Bearer Manager Client 
66, Fault Manager Client 68, Test Manager Client 70, 
Performance Manager Client 72 and Configuration Manage- 
ment Client 74 communicate with System Security Manager 
Server 58, Bearer Manager Server 76, Fault Manager Server 
78, Test Manager Server 80, Performance Manager Server 
82 and Configuration Management Server 84, respectively. 
System Command Interface 64 processes commands and 
messages being sent by Command Interpreter 62 to be 
compatible with, and suitable for receipt by, Servers 60, and 
also processes commands and messages being sent by 
Servers 60 to be compatible with, and suitable for receipt by, 
Command Interpreter 62. 

System Security Manager Client 54 in conjunction with 
System Security Manager Server 58 provide system security 
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administration for the Telecommunications Switch Manage- 
ment System, and for the accompanying Telecommunica- 
tions Switching System 230. These security-related func- 
tions will be discussed below in additional detail. 

5 Bearer Manager Client 66 in conjunction with Bearer 
Manager Server 76 enable the user of Remote Computer 10 
to perform various review, management and control func- 
tions regarding the status and configuration of Telecommu- 
nications Switching System 230. These functions include, 

10 but are not limited to, reviewing socket connections, per- 
forming bus management functions, and assigning available 
switching channels within Telecommunications Switching 
System 230, 

Fault Manager Client 68, in conjunction with Fault Man- 

15 ager Server 78, enables the user of Remote Computer 10 to 
review the fault status of, and the historical fault statistics 
for, Telecommunications Switching System 230. Test Man- 
ager Client 70, in conjunction with Test Manager Server 80, 
enables the user of Remote Computer 10 to perform various 

20 tests on Telecommunications Switching System 230. Test 
Manager Client 70 in conjunction with Test Manager Server 
80 first determine whether the requested test will disrupt the 
normal operation of Telecommunications Switching System 
230. Test Manager Client 70 in conjunction with Test 

25 Manager Server 80 then have the requested test performed 
by the appropriate client located in System Command Inter- 
face 64 and the appropriate corresponding Server 60. Test 
Manager Client 70 in conjunction with Test Manager Server 
80 next collate the results of the test performed, and return 

30 those results back to the user of Remote Computer 10 via 
System Management Interface 56 and System Manager 18. 

Performance Manager Client 72, in conjunction with 
Performance Manager Server 82, enables the user of Remote 

35 Computer 10 to review various data regarding the perfor- 
mance of Telecommunications Switching System 230. Per- 
formance Manager Client 72, in conjunction with Perfor- 
mance Manager Server 82, also enables the user of Remote 
Computer 10 to modify or reset, or set the thresholds on, the 

4Q various performance-monitoring data counters of Telecom- 
munications Switching System 230. 

Configuration Management Client 74, in conjunction with 
Configuration Management Server 84, enables the user of 
Remote Computer 10 to implement the creation, deletion, 

45 removal, restoration and modification of various attributes 
of the equipment and facilities of Telecommunications 
Switching System 230. 

Although System Command Interface 64, and Clients 54, 
66, 68, 70, 72 and 74 therein, and Servers 60 may be 

50 designed using any suitable software architecture, they may 
for example be designed using the well known CORBA 
architecture. In such a case where System Command Inter- 
face 64 and Servers 60 are designed using the CORBA 
architecture, System Command Interface 64 and Servers 60 

55 would communicate with one another using CORBA com- 
munications protocol Additionally, the application programs 
of Servers 60 may be constructed using any suitable method, 
but may be constructed using the well known C++ object- 
oriented programming language, for example. 

60 Messages and commands sent from Remote Computer 10 
to System Manager 18, and then to Command Interpreter 62, 
System Command Interface 64 and Servers 60 may for 
example represent commands from the Remote Computer 
user for reconfiguring the Telecommunications Switching 

65 System 230, or queries from the Remote Computer user 
regarding the status of the Telecommunications Switching 
System 230. On the other hand, messages and commands 
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sent from Servers 60 may for example represent messages 
regarding the status or configuration of the Telecommuni- 
cations Switching System 230, or commands to be directed 
to Remote Computer 10 instructing the user regarding how 
to reconfigure or determine the status of the Telecommuni- 5 
cations Switching System 230. 

The present invention also provides a Full Group Privi- 
leges Access Mechanism which provides security adminis- 
tration and account administration for the Telecommunica- 
tions Switch Management System and the accompanying 10 
Telecommunications Switching System 230. The Full Group 
Privileges Access Mechanism serves to ensure that only 
authorized users are able to access the Telecommunications 
Switch Management System and the Telecommunications 
Switching System 230. The Full Group Privileges Access 15 
Mechanism also serves to further ensure that, even if a 
particular user is generally authorized to access the system, 
the user cannot access any portion or function of the system 
which the user is not specifically authorized to access. 

As depicted in FIG, 1, the Full Group Privileges Access 20 
Mechanism is provided by System Manager 18 and Runtime 
Library 19 in conjunction with System Security Manager 
Client 54, which is located in System Management Interface 
56, and System Security Manager Server 58. The Full Group 
Privileges Access Mechanism maintains records of a variety 25 
of pertinent information in Runtime Library 19, in order to 
provide security and account administration for the system. 
Although records of any suitable information may be 
maintained, the Full Group Privileges Access Mechanism 
may for example maintain records regarding the list of 30 
authorized users, user groups, users' authorization levels, 
and the minimum authorization levels required for a user to 
execute each of the Telecommunications Switch Manage- 
ment System's available commands, or access each of the 
system's functions. 35 

More specifically, the Full Group Privileges Access 
Mechanism may for example maintain records of (a) autho- 
rized User IDs; (b) the date and time each User ID expires 
and therefore becomes unauthorized; (c) authorized Pass- 4Q 
words for each authorized User ID; (d) the date and time 
each Password expires and therefore becomes unauthorized; 
(e) the authorization level for each authorized User ID; (f) 
the User Group of which each user having an authorized 
User ID is a member; (g) the minimum authorization level 45 
required to execute each available command and access each 
available function; and (h) the User Group or Groups 
authorized to execute each available command and access 
each available function. 

When a user attempts to access the Telecommunications 50 
Switch Management System, the Full Group Privileges 
Access Mechanism compares the user's User ID and Pass- 
word against its records of authorized User IDs, the expi- 
ration date and time for each authorized User ID, authorized 
Passwords for each authorized User ID, and the expiration 55 
date and time for each authorized Password. The Full Group 
Privileges Access Mechanism will refuse the user access to 
the Telecommunications Switch Management System unless 
the user has a valid and unexpired User ID and Password, In 
the event that the Full Group Privileges Access Mechanism 60 
refuses to provide access to the Telecommunications Switch 
Management System, the Full Group Privileges Access 
Mechanism generates a record of the attempted unautho- 
rized access, so that unauthorized activities may be recorded 
and subsequently investigated if necessary. 65 

As discussed above, the Full Group Privileges Access 
Mechanism also maintains records of the authorization level 
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which has been assigned to each authorized user and User 
ID. A user's authorization level determines which functions 
of the Telecommunications Switch Management System the 
user is authorized to access, and which commands the user 
is authorized to execute. Thus, each function and command 
provided by the Telecommunications Switch Management 
System has a minimum authorization level assigned to it. In 
order for a user to access a particular system function or 
execute a particular system command, there must be 
assigned to that user an authorization level at least as high 
in number as the authorization level assigned to that function 
or command In this way, a user having a relatively high 
authorization level, such as a system administrator for 
example, can be provided more privileges and greater access 
to functions and commands than would an ordinary type of 
user who may, for example, only need to determine the 
status of the Telecommunications Switching System 230. 

Although there may be any number of different authori- 
zation levels, the Full Group Privileges Access Mechanism 
may be conligured to provide 4, 16, 64 or 256 different 
authorization levels, for example. In a system configured for 
16 different authorization levels (numbered 1 through 16), 
for example, a user having an authorization level of 6 would 
be able to access any function or execute any command 
having assigned to it an authorization level of 6 or lower. 
Similarly, a user having an authorization level of 1 would 
only be able to access functions or execute commands which 
have an authorization level of 1, whereas a user having an 
authorization level of 16 would be able to access all avail- 
able functions and execute all available commands. 

For the above -described example in which the Full Group 
Privileges Access Mechanism is configured to provide 16 
different authorization levels, an exemplary list of several 
functions and commands, together with their respective 
assigned minimum authorization levels, is presented below 
in Table 1. 

Manufacture and Sale of Tubes for Pneumatic Tires for 
vehicle Wheels 



TABLE 1 



Funclion/Commaad 


Minimum Authorization Level 


Create 


14 


Change 


13 


Delete 


15 


Display 


6 


Administration Functions 


16 



In this example, because functions and commands such as 
the exemplary Create, Change, Delete and Administration 
functions could potentially have a great effect on the Tele- 
communications Switch Management System and the asso- 
ciated Telecommunications Switching System 230, these 
functions and commands have been assigned the relatively 
high minimum authorization levels of 14, 13, 15 and 16, 
respectively. Thus, only users having authorization levels of 
14 through 36 would be able to access the Create function; 
only users having authorization levels of 13 through 16 
would be able to access the Change function; only users 
having authorization levels of 15 or 16 would be able to 
access the Delete function; and only users having an autho- 
rization level of 16 would be able to access the Adminis- 
tration Functions. 

On the other hand, because the exemplary Display func- 
tion would not affect the Telecommunications Switch Man- 
agement System to the extent that the exemplary Create, 
Change, Delete and Administration functions would, the 
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Display function has in this example been assigned the much 
lower minimum authorization level of 6. Thus, any users 
having authorization levels of 6 through 16 would be able to 
access and execute the Display function. 

In addition to maintaining records of authorized User IDs, 5 
Passwords, expiration dates, users' authorization levels, and 
the minimum authorization level assigned to each function 
and command, the Full Group Privileges Access Mechanism 
also maintains records regarding User Groups, a list of 
authorized users assigned to each User Group, and a list of 
functions and commands which members of each User 
Group are authorized to access. User Groups are an addi- 
tional mechanism by which the Full Group Privileges 
Access Mechanism provides security administration and 
account administration for the Telecommunications Switch 
Management System. 15 

Each User Group comprises a list of authorized users 
which have been assigned to that User Group. It is possible 
for a particular user to be assigned to more than one User 
Group. In addition, each User Group has assigned to it a list 
of functions which members of that User Group are autho- 20 
rized to access, and a list of commands which members of 
that User Group are authorized to execute. Thus, in order for 
a particular user to access a particular function or execute a 
particular command of the Telecommunications Switch 
Management System, the user must be a member of one or 25 
more of the User Groups authorized to access that function 
or execute that command 

Although there may be any type and number of User 
Groups, an exemplary set of User Groups might include a 
Tester Group, Maintenance Group and Administrator Group. 30 
Each of these User Groups would have associated with it a 
set of functions which each member of the respective User 
Group would be entitled to access, and a set of commands 
which each member of the respective User Group would be 
entitled to execute. Using the same set of exemplary func- 35 
tions and commands presented in Table 1 above, an exem- 
plary set of User Groups, together with the functions and 
commands which members of each User Group are entitled 
to access and execute, are presented below in Table 2. 
Manufacture and Sale of Tubes for Pneumatic Tires for 40 
Vehicle Wheels 

TABLE 2 







Function/Command Access 




45 


User Group 


Create 


Change 


Delete 


Display 


Admin. Fens. 




Tester 


No 


No 


No 


Yes 


No 




Maintenance 


Yes 


Yes 


No 


Yes 


No 




Administrator 


Yes 


Yes 


Yes 


Yes 


Yes 


50 



In the example presented in Table 2, members of the Tester 
User Group have been authorized to access the Display 
function, but not the Create, Change, Delete or Administra- 
tion functions; members of the Maintenance User Group 55 
have been authorized to access the Create, Change and 
Display functions, but not the Delete or Administration 
functions; and members of the Administrator User Group 
have been authorized to access each of the Create, Change, 
Delete, Display and Administration functions. 60 

Thus, in the present example, an authorized user who is a 
member of the Administrator User Group would have access 
to a greater number of functions and commands than would 
members of the Maintenance and Tester User Groups, and 
members of the Maintenance User Group would have 65 
greater access to commands and functions than would 
members of the Tester User Group. As a general rule, 



relatively few User Groups would be provided access to 
functions and commands which might have a relatively large 
effect on the Telecommunications Switch Management Sys- 
tem and the associated Telecommunications Switching Sys- 
tem 230, such as the Delete and Administration functions On 
the other hand, a larger number of User Groups typically 
would be provided access to functions and commands which 
would have little or no effect on the system, such as the 
Display function. 

Typically, a User Group, such as the Administrator User 
Group, would include only user members such as system 
administrators who would require relatively complete access 
to the functions and commands provided by the Telecom- 
munications Switch Management System. Accordingly, the 
exemplary Administrator User Group would be provided 
access to most or all of the available functions and 
commands, as in the illustrative example provided in Table 
2, On the other hand, a User Group, such as the Tester User 
Group, would include user members authorized to review 
the status and configuration of the system, but not authorized 
to alter or reconfigure the system. Accordingly, the Tester 
User Group would be provided access only to functions and 
commands which could have little or no impact on the 
system, such as the Display function. 

As discussed above, in addition to maintaining records 
relating to the User Groups, the Full Group Privileges 
Access Mechanism also maintains records relating to the 
users' authorization levels and the minimum authorization 
level assigned to each function and command. In order to 
provide security administration for the Telecommunications 
Switch Management System, the Full Group Privileges 
Access Mechanism uses the records relating to the User 
Groups in combination with the records relating to autho- 
rization levels. 

More specifically, in order for a user to access a particular 
function or execute a particular command of the Telecom- 
munications Switch Management System, the Full Group 
Privileges Access Mechanism typically would require that 
the user both (a) be a member of a User Group authorized 
to access the desired function or execute the desired 
command, and (b) have an authorization level at least as 
high as the minimum authorization level assigned to the 
function or command. Although the Full Group Privileges 
Access Mechanism may also be configured to require only 
that (a) the user be a member of one of the User Groups 
authorized to access the desired function or execute the 
desired command, or (b) the user have an authorization level 
at least as high as the minimum authorization level assigned 
to the function or command, the Full Group Privileges 
Access Mechanism typically would be configured to require 
that a user meet both, rather than only one of, these two 
requirements. In providing security administration by using 
the records relating to the User Groups in combination with 
the records relating to authorization levels, the Full Group 
Privileges Access Mechanism can provide different access 
privileges to different users who are members of the same 
User Group. 

In the event that a user attempts to access a function or 
execute a command which the user is not authorized to 
access or execute, the Full Group Privileges Access Mecha- 
nism prevents the user from accessing that function or 
executing that command Whenever the Full Group Privi- 
leges Access Mechanism refuses to permit a user to access 
a function or execute a command, the Full Group Privileges 
Access Mechanism generates a record of the attempted 
unauthorized access, so that unauthorized activities may be 
recorded and subsequently investigated, if necessary. 



08/14/2003, EAST Version: 1.04.0000 



US 6,266,695 Bl 



15 



16 



FIGS. 3A-B depict an exemplary process flow for the 
operation of the Full Group Privileges Access Mechanism, 
beginning with Block 86. When a user attempts to access the 
Telecommunications Switch Management System depicted 
in FIG. 1 via Remote Computer 10, Remote Computer 10 5 
which operates as a GUI Browser provides the user's User 
ID and Password to System Manager 18, as shown in Block 
86. As shown in Block 88, System Manager 18, in conjunc- 
tion with System Security Manager Client 54 and System 
Security Manager Sever 58, then access the records con- 10 
taming the list of valid User IDs and Passwords, which 
records are maintained in the System Manager Runtime 
Library 19, and compare the user's User ID and Password to 
the list of valid User IDs and Passwords. As shown in Blocks 
90 and 92, if the Full Group Privileges Access Mechanism 15 
determines that the user's User ID or Password is not valid, 
the Full Group Privileges Access Mechanism generates a 
record of the attempted unauthorized access, and transmits 
a Failed Logon message to Remote Computer 10, which in 
turn displays the message to the user, 20 

If on the other hand the Full Group Privileges Access 
Mechanism determines the user's User ID and Password to 
be valid, the Full Group Privileges Access Mechanism 
establishes a logon session and a corresponding session key, 
as shown in Blocks 90 and 94. In determining whether the 25 
user's User ID and Password are valid, the Full Group 
Privileges Access Mechanism typically would reference the 
above-described records of authorized User IDs, authorized 
Passwords, and the expiration date and time for each User 
ID and Password, which records are maintained in System 30 
Manager Runtime Library 19. 

As shown in Block 96, if a logon session is established, 
the Full Group Privileges Access Mechanism starts a tim- 
eout clock which will terminate the logon session after a 
predetermined period of inactivity by the user. Thus, if a user 35 
at Remote Computer 10 is logged into the Telecommunica- 
tions Switch Management System for a certain period of 
time without making any entries into Remote Computer 10, 
the system will automatically terminate the user's logon 
session. This prevents unauthorized users from accessing the 40 
system if an authorized user who is logged on leaves Remote 
Computer 10 without first terminating the logon session. 

As shown in Block 98, when the authorized user wishes 
to access a function or execute a command of the Telecom- 
munications Switch Management System, the user issues a 45 
command using Java Applet 22 running on Remote Com- 
puter 10. The Java Applet 22 running on Remote Computer 
10 then flattens the data representative of the user's User ID, 
the session key and the issued command, and sends this 
flattened data to System Manager 18, as shown in Blocks 50 
100 and 102, The Full Group Privileges Access Mechanism 
then extracts the User ID, the session key and the issued 
command from the flattened data, and compares this infor- 
mation with the information in the Full Group Privileges 
Access Mechanism's records relating to User Groups and 55 
authorization levels which are maintained in System Man- 
ager Runtime Library 19, as shown in Block 104. Based on 
the user's authorization level and the User Groups of which 
the user is a member, the Full Group Privileges Access 
Mechanism determines whether the user is authorized to 60 
execute the command or to access the system function which 
the command accesses. In determining whether the user is 
authorized to execute the command or access the function, 
the Full Group Privileges Access Mechanism typically 
would reference the above-described records of the User 65 
Groups of which the user is a member, the User Groups 
authorized to execute each command and access each 



function, the user's authorization level, and the minimum 
authorization level required to execute each available com- 
mand and access each available function. 

As shown in Blocks 106 and 108, if the user is not 
authorized to execute the command or access the function, 
the Full Group Privileges Access Mechanism generates a 
record of the attempted unauthorized access, and sends a 
message to Remote Computer 10 indicating that the user's 
attempt to access the Telecommunications Switch Manage- 
ment System has failed. As shown in Blocks 106 and 110, if 
the user is authorized to execute the command or access the 
function, System Manager 18 transmits flattened data rep- 
resentative of the issued command to System Management 
Interface 56. System Management Interface 56 then sends 
the issued command to the appropriate Server 60 via Com- 
mand Interpreter 62 and the appropriate Client in System 
Command Interface 64, as shown in Block 112. 

As shown in Block 114, the appropriate Server 60 
executes the command and then provides a response to Java 
Applet 22 running on Remote Computer 10, in the form of 
a message routed to Remote Computer 10 through System 
Management Interface 56 and System Manager 18. The Java 
Applet running on Remote Computer 10 displays a message 
denoting the response from Server 60 on Remote Computer 
10 for the user, as shown in Block 116. Although the 
applications of Servers 60 may be constructed using any 
suitable method, they may be constructed using the well 
known C++ programming language, for example. 

The FIG. 1 system also includes a Graphical Shelf Navi- 
gator which provides a convenient GUI interface for access- 
ing and implementing the features and functions of the 
Telecommunications Switch Management System. The 
Graphical Shelf Navigator enables the user to access and 
implement the Telecommunications Switch Management 
System's features and functions simply by making appro- 
priate selections from a series of graphical displays and 
menus. The user can use the Graphical Shelf Navigator to 
conveniently and easily access the Telecommunications 
Switching System 230 for any purpose, such as for the test 
and reconfiguration of the Telecommunications Switching 
System 230 or for the monitoring of the Telecommunica- 
tions Switching System 230 's performance and faults. 

The Graphical Shelf Navigator operates by prompting the 
user to select the particular portion of the Telecommunica- 
tions Switching System 230 the user wishes to access or 
perform an operation on, and by also prompting the user to 
select the particular function or command the user wishes to 
execute on the selected portion of the Telecommunications 
Switching System 230. The user may implement the desired 
selections using any appropriate keystrokes on Remote 
Computer 10, Typically, however, the user implements the 
desired selections using any type of well known mouse 
commands, such as by moving the mouse to place a cursor 
on the portion of the display corresponding to the desired 
selection, and by then "clicking" the mouse on that portion 
of the display. 

FIG. 4 depicts the first of the Graphical Shelf Navigator's 
series of graphical displays. The graphical display depicted 
in FIG. 4 represents the cabinet, shelves and application 
cards (i.e., the printed circuit boards which contain elec- 
tronic components) which compose the Telecommunica- 
tions Switching System 230 's electronic hardware, as well 
as the particular shelf of application cards which the user 
selects Specifically, Cabinet Graphic 120 represents the 
cabinet which contains the electronic hardware of Telecom- 
munications Switching System 230. Shelf Graphics 122, 
124, 126 and 128 represent the shelves within the cabinet 
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which contain the application cards. Application Card 138 as being selected, the user may select any application 

Graphics 130 represent the application cards which contain card. The designation of any application card which has 

the Telecommunications Switching System 230 's electronic been selected will be denoted in Status Bar 172. 

components The darker shading of Shelf Graphic 122, and Once the user utilizes the graphical display depicted in 

of the Application Card Graphics 130 contained therein, 5 FIG. 5 to select a particular application card and a function 

denotes that the user has selected that shelf and those to be performed on that application card, the user is pre- 

application cards The selection of this shelf is denoted in sented with the next and final display of the Graphical Shelf 

Status Bar 132; in the particular example depicted in FIG. 4, Navigator's series of displays, which display enables the 

the selected shelf of application cards is designated as "Unit user to fully implement the selected function on the selected 

0". Thus, Status Bar 132 serves to denote the designation of 10 application card. One example of such a display is depicted 

the particular shelf selected. in FIG. 6. FIG. 6 depicts such a display in the particular case 

Once the user has selected the desired shelf, the user then where, in the graphical display depicted in FIG. 5, the user 

selects from Icon Bar 133 the function which the user desires selects the function which is designated by "Create" to be 

to perform on the selected shelf. In the graphical display performed on the application card which is designated by 

depicted in FIG. 4, the functions available to be performed is "STGS". In order to implement the function designated by 

on a selected shelf are designated as "Create", "Display", "Create" on the application card designated by "STGS", the 

"Delete", "Refresh", "Zoom In", "Help", and "Close". user configures each of the parameters provided in Configu- 

Menu Bar 134 provides the user access to numerous menu ration Lines 176 as desired, and then invokes the "Apply" 

functions and/or files related to the Graphical Shelf Command 178. If, on the other hand, the user decides to not 

Navigator, and will be discussed below in additional detail. 20 implement the function designated by "Create" on the 

Although the example of FIG. 4 depicts four shelves as application card designated by "STGS", the user invokes the 

containing application cards, as a general rule either one, "Dismiss" command 180. 

two or three shelves can be empty. Similarly, although the Although FIG. 6 depicts the Graphical Shelf Navigator's 

example of FIG. 4 depicts the upper shelf (represented by display in the particular case where the user has selected the 

Shelf Graphic 122) as being selected, the user may select 25 function designated by "Create" to be performed on the 

any shelf. The designation of any shelf which has been application card designated by "STGS", the Graphical Shelf 

selected will be denoted in Status Bar 132. Navigator can provide such a display for every combination 

FIG. 5 depicts an example of one of the next graphical of available application cards and available functions. The 

displays in the Graphical Shelf Navigator's series of graphi- visual appearance of each display, and the particular Con- 

cal displays. The graphical display depicted in FIG. 5 would 30 figuration Lines 176 provided in each display, depend on the 

result if, in the graphical display depicted in FIG. 4, the user particular application card and the function selected by the 

selected the function designated by "Zoom In" to be per- user. 

formed on the selected shelf. The graphical display depicted FIG. 7 depicts an exemplary process flow for the opera- 

in FIG. 5 represents the shelf of application cards which the tion of the Graphical Shelf Navigator example depicted in 

user selected in the graphical display depicted in FIG. 4, as 35 FIGS. 4-6. As shown in Block 182, the Graphical Shelf 

well as the particular application card within the shelf which Navigator begins by displaying to the user the graphical 

the user selects. Specifically, application Card Graphics 136, display depicted in FIG. 4. While viewing this graphical 

138, 140, 142, 144, 146, 148, 150, 152, 154, 156, 158, 160, display, the user utilizes Shelf Graphics 122, 124, 126 and 

162, 164 and 166 represent the individual application cards 128 to select the shelf of application cards on which the user 

located in that shelf; the aggregate of all of these application 40 desires to perform a function, as shown in Block 184. The 

cards is collectively represented by Application Card Graph- user then uses Icon Bar 133 to select the function to be 

ics 130. Empty Application Card Slot Graphics 168 and 170 performed on the selected shelf of application cards, as 

represent empty application card slots located in that shelf, shown in Block 186. 

The darker shading of Application Card Graphic 138 As shown in Block 188, the Graphical Shelf Navigator 

denotes that the user has selected that application card. The 45 then changes the display to the graphical display depicted in 

selection of that application card is denoted in Status Bar FIG. 5. While viewing this graphical display, the user then 

172. In the particular example depicted in FIG. 5, the uses Application Card Graphics 130 to select the specific 

selected application card is designated as "STGS". Thus, application card on which the user desires to perform a 

Status Bar 172 serves to denote the designation of the function, as shown in Block 190. As shown in Block 192, the 

particular application card selected. so user then utilizes Icon Bar 173 to select the function to be 

Once the user has selected the desired application card, performed on the selected application card. As shown in 

the user then selects from Icon Bar 173 the function which Block 194, the Graphical Shelf Navigator then changes the 

the user desires to perform on the selected application card. display to the display depicted in FIG. 6, As shown in Block 

In the particular example depicted in FIG. 5, the functions 196, the user appropriately configures each of the parameters 

available to be performed on a selected application card are 55 provided in Configuration Lines 176. Finally, in order to 

designated as "Create", "Display", "Change", "Delete", execute the selected function on the selected application 

"Refresh", "Help", and "Close" Menu Bar 174 provides the card, the user invokes the "Apply" Command 178, as shown 

user access to numerous menu functions and/or files related in Block 198. 

to the Graphical Shelf Navigator, and will be discussed The Graphical Shelf Navigator also provides pull -down 

below in additional detail. > 60 menus as an alternative way for a user to access and 

Although the example of FIG. 5 depicts a shelf having implement the features and functions of the Telecommuni- 

sixteen application cards and two empty application card cations Switch Management System. A user has the option 

slots, as a general rule a shelf may contain any number of to use these pull-down menus instead of the above-described 

application card slots and any number of application cards, series of graphical displays depicted in FIGS. 4 and 5, in 

up to and including the number of application card slots. 65 order to access and implement any of the features and 

Similarly, although the example of FIG. 5 depicts the functions of the Telecommunications Switch Management 

application card represented by Application Card Graphic System. 
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As with the series of graphical displays described above, 
the pull-down menus operate by prompting the user to select 
the particular portion of the Telecommunications Switching 
System 230 the user wishes to access or perform an opera- 
tion on, and by also prompting the user to select the 5 
particular function or command the user wishes to execute 
on the selected portion of Telecommunications Switching 
System 230. The user may implement the desired pull-down 
menu selections using any appropriate keystrokes on 
Remote Computer 10, but typically implements these selec- 10 
tions using any type of well known mouse commands, such 
as by moving the mouse to place a cursor on the portion of 
the pull-down menu corresponding to the desired selection, 
and by then "clicking" the mouse on that portion of the 
menu. 15 

FIG. 8 depicts the Graphical Shelf Navigator's Pull-Down 
Menus 200 and 202, which provide an alternative way for a 
user to implement the selections which can be made using 
the graphical display depicted in FIG. 4. Although the same 
Cabinet Graphic 120 and Icon Bar 133 depicted in FIG. 4 20 
also appear in FIG. 8, the Cabinet Graphic 120 and Icon Bar 
133 become inactive once the user activates Pull-Down 
Menus 200 and 202. Once Cabinet Graphic 120 and Icon 
Bar 133 become inactive, they can no longer be used to 
select portions of the Telecommunications Switching Sys- 25 
tem 230, or functions to be performed thereon. 

The user activates Pull-Down Menu 200 by using Menu 
Bar 134. In the exemplary Menu Bar 134 depicted in FIG. 
8, the available selections are designated "File", "Config", 
"Unit", "Device", "Facility", "Refresh", and "Help". FIG. 8 30 
depicts the example where the user has selected the 
"Device" option from Menu Bar 134. Based on the user's 
selection of the "Device" option, the Graphical Shelf Navi- 
gator generates Pull-Down Menu 200, which provides the 
user with a selection of devices, namely application cards, 35 
having the designations "HLTP", "OTM", "STSM", 
"PCM", "MTXI", "SCAN", "ECHO", and "STGS". The 
user then selects the desired application card from Pull- 
Down Menu 200. FIG. 8 depicts the particular example 
where the user has selected the application card designated 40 
by "STGS". 

Once the user has selected the desired application card 
from Pull-Down Menu 200, the Graphical Shelf Navigator 
then generates Pull-Down Menu 202, which provides the 
user with a selection of functions which can be performed on 45 
the selected application card. In the example of FIG. 8, the 
functions available are designated by "Create", "Change", 
"Display", and "Delete" FIG. 8 depicts the example where 
the user selects the function designated by "Create". 

Although FIG. 8 depicts Pull-Down Menu 200 in the 50 
particular case where the user has selected the option des- 
ignated as "Device" from Menu Bar 134, the Graphical 
Shelf Navigator provides an appropriate pull-down menu for 
each available option in Menu Bar 134. The appearance of 
each of those pull-down menus, and the selections provided 55 
therein, depend on the option selected from menu bar 134. 
Similarly, although FIG. 8 depicts Pull-Down Menu 202 in 
the particular case where the user has selected the applica- 
tion card designated as "STGS" from Pull-Down Menu 200, 
the Graphical Shelf Navigator provides an appropriate pull- 60 
down menu for each available application card appearing in 
Pull-Down Menu 200. The appearance of each of those 
pull-down menus, and the selections provided therein, 
depend on the application card selected from Pull-Down 
Menu 202. 65 

In addition to accessing Pull-Down Menu 202 from 
Pull-Down Menu 200, a user alternatively can access Pull- 



Down Menu 202 from the graphical display depicted in FIG. 
56 FIG. 9 depicts the same graphical display as is depicted 
in FIG. 5, which display represents a single shelf of appli- 
cation cards of Telecommunications Switching System 230 
In order to access Pull-Down Menu 202 from the display 
depicted in FIG. 9, the user selects an application card from 
Shelf Graphic 122. Once the user has selected an application 
card, the Graphical Shelf Navigator then generates Pull- 
Down Menu 202, which is the same as the Pull-Down Menu 
202 depicted in FIG. 8. As in the example depicted in FIG. 
8, the user then selects from the Pull-Down Menu 202 in 
FIG, 9 a function to be performed on the selected application 
card. Although FIG. 9 depicts Icon Bar 173, which is also 
depicted in FIG. 5, Icon Bar 173 becomes inactive once the 
user activates Pull-Down Menu 202. Once Icon Bar 173 
becomes inactive, it cannot be used to select functions to be 
performed on the selected application card. 

In the example depicted in FIG. 9, as in the example of 
FIG. 5, the darker shading of Application Card Graphic 138 
denotes that the user has selected that application card. The 
selection of that application card is denoted in Status Bar 
172. In the particular example depicted in FIG. 9, the 
selected application card is designated as "STGS". Status 
Bar 172 denotes the designation of the particular application 
card selected. 

Once the user has utilized Pull Down Menus 200 and 202 
to select the desired application card and function, 
respectively, the Graphical Shelf Navigator then provides 
the user with the final display which enables the user to fully 
implement the selected function on the selected application 
card. This final display is the same final display which the 
Graphical Shelf Navigator would provide if the user had 
selected the application card and function using the Graphi- 
cal Shelf Navigator's series of graphical displays (such as 
are depicted in FIGS. 4 and 5, for example), rather than 
Pull-Down Menus 200 and 202. 

One example of such a display is depicted in FIG. 6. FIG. 
6 depicts such a display in the particular case where, using 
the pull-down menus depicted in either FIGS. 8 or 9, the user 
selects the function which is designated by "Create" to be 
performed on the application card which is designated by 
"STGS". In order to implement the function designated by 
"Create" on the application card designated by "STGS", the 
user configures each of the parameters provided in Configu- 
ration Lines 176 as desired, and then invokes the "Apply" 
Command 178. If, on the other hand, the user decides to not 
implement the function designated by "Create" on the 
application card designated by "STGS", the user invokes the 
"Dismiss" command 180. 

Although FIG, 6 depicts the Graphical Shelf Navigator's 
display in the particular case where the user has used 
Pull- Down Menus 200 and 202 to select the function des- 
ignated by "Create" to be performed on the application card 
designated by "STGS", the Graphical Shelf Navigator pro- 
vides such a display for every combination of available 
application cards and available functions. The visual appear- 
ance of each display, and the particular Configuration Lines 
176 provided in each display, depend on the application card 
and the function selected by the user. 

FIG. 10 depicts an exemplary process flow for the opera- 
tion of the Graphical Shelf Navigator pull-down menu 
example depicted in FIG. 8. As shown in Block 204, the 
Graphical Shelf Navigator begins by displaying to the user 
the graphical display depicted in FIG. 8. The user then 
selects the desired option from Menu Bar 134. As shown in 
Blocks 208 and 210, respectively, the Graphical Shelf Navi- 
gator then generates the appropriate Pull-Down Menu 200, 
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and also deactivates Cabinet Graphic 120 and Icon Bar 133. viding an ability to perform management functions on 

Using Pull-Down Menu 200, the user selects the specific the telecommunications switching system; 

application card on which the user desires to perform a a fault manager client building block in communication 

function, as shown in Block 212. As shown in Block 214, the with a fault manager server building block for provid- 

Graphical Shelf Navigator then generates the appropriate 5 ing an ability to review faults which have occurred in 

Pull-Down Menu 202. Using Pull-Down Menu 202, the user the telecommunications switching system; 

then selects the function to be performed on the selected a test manager client building block in communication 

application card, as shown in Block 216. with a test manager server building block for providing 

As shown in Block 218, the Graphical Shelf Navigator a " ability to perform tests on the telecommunications 

then changes the user's display to the display depicted in 10 switching system; 

FIG. 6. As shown in Block 220, the user appropriately a performance manager client building block in commu- 

configures each of the parameters provided in Configuration nicaiion with a performance manager server building 

Lines 176. Finally, in order to execute the selected function block for providing an ability to review the perfor- 

on the selected application card, the user invokes the n*?™ of the telecommunications switching system; 

"Apply" Command 178, as shown in Block 222. 15 and 

Although the present invention and its advantages have a configuration management client building block in 

been described in detail, it should be understood that various communication with a configuration management 

changes, substitutions and alterations can be made therein ?™ T ^*wg blo f f h for providing an ability to con- 

* j *■ * *u - i r*u • figure attributes of the telecommunications switching 

without departing from the spirit and scope of the invention & & 

as defined by the appended claims. 20 3 ^^communications switch management system of 

Wnat is claimed is. c)ailn 1> wnerem said system management interface building 

1. A telecommunications switch management system for block comprises , command interpreter building 
providing access to a telecommunications switching system, 51ock in communication with said system manager building 
comprising: block, and in communication with said system command 

a system manager building block in communication with 25 interface building block containing said at least one client 

a remote computer: building block, wherein said system manager building block 

a system management interface building block in com- provides communication between said remote computer and 

munication with said system manager building block, said c ™ nd interpreter building block, and wherein said 

said system management interface building block hav- <*™n»BA interpreter building block provides communica- 

ing a system command interface building block con- 30 Uon between ^W*?* ™nager building block and said 

taining at least one client building block; and f y stem interface building block containing said at 

... , .... . 1 1 • • .• -.l. ' east one client building block. 

at least one server building block in communication with 4 The teleOTmmunic * ions switch managem e„t system of 

said at least one client budding block in said system daim 3 wherejn $aid >( , eas , Qne ^ ^ > lock fa 

management mterface building block, said at least one 35 commumcation with said at leas , one MIwr ^ block 

server building block being in communication with the fa hw dxs a s6curf ffla ^ b 6 uM 

telecommunications switchmg system, wherein said b , ock . J mmunicilioa whh a s ' ysl6 m security manager 

system manager building block provides commumca- ^ ^ ^ for ^ \ hc ^communications 

tion between said remote computer and said system ^ ^ ^ ^ 

management interface building block, and wherein said 4Q «. The 6 telecommunications s ' witch managem e„t system of 

system management interface building block provides c , aim 3 wherejn sajd Qne cUeQt * > 

communication between said system manager building M ' ■ t - „, itU -,i nt rtM M ™, k„*i?*„„ u-i^u 

J , ,f , iL . communication with said at least one server building block 

block and said at least one server buildme block, so that . . i- -u- i_T i ■ 

•j . T ■ .j u "" u, "& ~ ' , ! further comprises a bearer manager client building block in 

said remote computer is provided access to the tele- f. ... , . , 

v, uuipuiw « iviv^i a * u iu communication with a bearer manager server building block 

communication switching system, said remote com- f ... , .... t c i£ 

vvju o o^oivm, o 45 f or provic i m g an ability to perform management functions on 

puter operable to perform a function on a selected ^ telecomm ^ icatic 4 switchi s 

application card within the telecommunication switch- 6 Jhe telecommunicatioQS switch management system of 

mg system m response to user inputs and m response to ^ 3 wherein said &{ ^ Qne ^ * ^ 

the user having an appropriate authorization level asso- t - ... • « . i A „ * ■ . M j- U t 1 

j • u 1 n. . , communication with said at least one server building block 

ciated with the function; and r <u - c u .7 1 • 

' 50 further comprises a fault manager client building block in 

wherein said system manager building block and said communication with a fault manager server building block 

system management interface building block conform for prov i t ii n g an ability to review faults which have occurred 

to a common object request broker architecture in the telecommunications switching system. 

(CORBA), and wherein said system manager building 7 Xhe telecommunications switch management system of 

block is configured to communicate with said system 5S claim ^ wherein said at kast one cliem building block ^ 

management interface building block using a CORBA communication with said at least one server building block 

communication protocol. further comprises a lest manager client building block in 

2. The telecommunications switch management system of communication with a test manager server building block 
claim 1, wherein said at least one client building block in for prov iding an ability to perform tests on the telecommu- 
communication with said at least one server building block 60 mcat jons switching system. 

further comprises: g Th e telecommunications switch management system of 

a system security manager client building block in com- claim 3, wherein said at least one client building block in 

munication with a system security manager server communication with said at least one server building block 

building block for providing the telecommunications further comprises a performance manager client building 

switching system with security functions; 6S block in communication with a performance manager server 

a bearer manager client building block in communication building block for providing an ability to review the per- 

with a bearer manager server building block for pro- formance of the telecommunications switching system. 
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9. The telecommunications switch management system of 
claim 3, wherein said at least one client building block in 
communication with said at least one server building block 
further comprises a configuration management client build- 
ing block in communication with a configuration manage- 5 
ment server building block for providing an ability to 
configure attributes of the telecommunications switching 
system. 

10. The telecommunications switch management system 

of claim 1, wherein said remote computer is configured to 10 
communicate with said system manager building block 
using an internet inter-ORB protocol (HOP) communica- 
tions protocol. 

11. The telecommunications switch management system 

of claim 1, wherein said remote computer is configured to 15 
communicate with said system manager building block 
using a hypertext transport protocol (HTTP) communica- 
tions protocol. 

12. The telecommunications switch management system 

of claim 3, wherein said system manager building block and 20 
said command interpreter building block conform to a 
common object request broker architecture (CORBA), and 
wherein said system manager building block communicates 
with said command interpreter building block using a 
CORBA communications protocol. 25 

13. The telecommunications switch management system 
of claim 3, wherein said command interpreter building block 
is configured to communicate with said system command 
interface building block containing said at least one said 
client building block using a library application program- 30 
ming interface (API) communications protocol. 

14. The telecommunications switch management system 
of claim 1, wherein said at least one client building block 
and said at least one server building block conform to a 
common object request broker architecture (COBRA), and 35 
wherein said at least one client building block is configured 

to communicate with said at least one server building block 
using a CORBA communications protocol. 

15. A telecommunications switch management system for 
providing access to a telecommunications switching system, 40 
comprising: 

a system manager building block having a CORBA archi- 
tecture and being in communication with a remote 
computer; 

a command interpreter building block having a CORBA 45 
architecture and being in communication with said 
system manager building block using a CORBA com- 
munications protocol; 

a system command interface building block in commu- 5Q 
nication with said command interpreter building block 
using a library application programming interface 
(API) communications protocol, said system command 
interface building block having a system security man- 
ager client building block having a CORBA 55 
architecture, a bearer manager client building block 
having a CORBA architecture, a fault manager client 
building block having a CORBA architecture, a test 
manager client building block having a CORBA 
architecture, a performance manager client building 6Q 
block having a CORBA architecture, and a configura- 
tion management client building block having a 
CORBA architecture; 

a system security manager server building block having a 
CORBA architecture and being in communication with 
said system security manager client building block 



using a CORBA communications protocol, for provid- 
ing the telecommunications switching system with 
security functions; 

a bearer manager server building block having a CORBA 
architecture and being in communication with said 
bearer manager client building block using a CORBA 
communications protocol, for providing an ability to 
perform management functions on the telecommunica- 
tions switching system; 

a fault manager server building block having a CORBA 
architecture and being in communication with said fault 
manager client building block using a CORBA com- 
munications protocol, for providing an ability to review 
faults which have occurred in the telecommunications 
switching system; 

a test manager server building block having a CORBA 
architecture and being in communication with said test 
manager client building block using a CORBA com- 
munications protocol, for providing an ability to per- 
form tests on the telecommunications switching sys- 
tem; 

a performance manager server building block having a 
CORBA architecture and being in communication with 
said performance manager client building block using 
a CORBA communications protocol, for providing an 
ability to review the performance of the telecommuni- 
cations switching system; and 

a configuration management server building block having 
a CORBA architecture and being in communication 
with said configuration management client building 
block using a CORBA communications protocol, for 
providing an ability to configure attributes of the tele- 
communications switching system, said server building 
blocks being in communication with the telecommu- 
nications switching system, wherein said system man- 
ager building block provides communication between 
said remote computer and said command interpreter 
building block,' wherein said command interpreter 
building block provides communication between said 
system manager building block and said system com- 
mand interface building block having said client build- 
ing blocks, and wherein said system command inter- 
face building block having said client building blocks 
provides communication between said command inter- 
preter building block and said server building blocks, 
so that said remote computer is provided access to the 
telecommunications switching system, said remote 
computer operable to perform a function on a selected 
application card within the telecommunications switch- 
ing system in response to user inputs and in response to 
the user having an appropriate authorization level asso- 
ciated with the function. 

16. The telecommunications switch management system 
of claim 15, wherein said remote computer is configured to 
communicate with said system manager building block 
using an internet inter-ORB protocol (HOP) communica- 
tions protocol. 

17. The telecommunications switch management system 
of claim 15, wherein said remote computer is configured to 
communicate with said system manager building block 
using a hypertext transport protocol (HTTP) communica- 
tions protocol. ' 
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